Code Review

Overview

Adds OWNCLOUD_OPENID_CONNECT, a JSON-encoded env var decoded into $config['openid-connect'] (system config) for the openidconnect app. Closes #492. Touches three files: CHANGELOG.md, ENVIRONMENT.md, and the v24.04 config template. +21/-0.

Correctness — verified against the app

I traced the consuming code in owncloud/openidconnect:

• Client::getOpenIdConfig() (lib/Client.php:103) reads the app-value first, and falls back to getSystemValue('openid-connect', null) — returning it directly as the config used with array access (['auto-provision'], ['mode'], ...).
• That means the system-config value must be a PHP array, which is exactly what this PR writes (json_decode(..., true)). A raw JSON string in system config would break the app's array access — so decoding to an array here is not merely convenient, it is required. Correct.
• The app's own README confirms the shape: appid openidconnect, configkey openid-connect, value a JSON-String; the documented example matches the PR's example almost verbatim.

One nit for the PR description (not the code): "The app itself json_decodes this value" is only true for the DB/app-value path; the system-value path this env var populates is consumed as a raw array. The code does the right thing regardless — worth tightening the wording.

Conventions — clean

• The block is a faithful copy of the established OWNCLOUD_LOG_CONDITIONS / OWNCLOUD_USER_BACKENDS idiom (getenv() != '' → json_decode(_, true) → is_array guard → assign). Invalid JSON safely leaves the key unset. Consistent with neighbors.
• v24.04-only is correct. I checked master: the three most recent additions (USER_BACKENDS Missing envvar for 'user_backends' #490, FORBID_MAP Missing envvar for loginPolicy.groupLoginPolicy.forbidMap #493, CUSTOMGROUPS Missing envvars for customgroups.xxx configurations #491) all landed in v24.04 only, not v22.04 — v22.04 retains older vars but no longer receives new ones. So skipping v20.04/v22.04 matches current practice. (Minor: the PR body calls v22.04 "frozen"; more precisely it's "no longer receiving new env vars" — it still contains older ones.)
• CHANGELOG entry (## 2026-07-09, * Added, issue link) matches the existing format exactly.
• ENVIRONMENT.md entry is alphabetically placed (between OBJECTSTORE_* and OPENSSL_CONFIG) and documents the nested structure with a doc link. Good.

Security

• client-secret lands in an env var and is decoded into config. This is consistent with how other secrets (LDAP, S3 keys) are already handled here, so no new exposure class — but the doc could note that the JSON contains a secret and should be sourced from a secrets store / *_FILE pattern if one exists. Not blocking.
• No injection surface: value is JSON-parsed, never eval'd or string-interpolated into PHP.

Test coverage

• The repo has no unit/behavioral harness for the template (CI main.yml only builds the image + a trivial php -r "echo 'OK'" smoke test), so the manual php -r round-trip verification in the PR body is the appropriate level of proof here. Matches how sibling env vars were merged.

Verdict

Correct, convention-aligned, and verified against the consuming app's actual read path. Approve. Only optional polish: tighten the two wording points above (app decode path; "frozen" v22.04) and optionally note the secret-handling caveat in the docs.